REJECTING A BATCH OF SECURE COMMANDS IN A SECURE CHANNEL

专利摘要:
The invention relates to communications between master and slave devices. An intermediary third receives, from the master, a batch of pre-generated secure commands; plays it so as to send sequentially, to the slave, said commands. The batch includes an initial command indicating the establishment of a secure channel with a session key dependent on a sequence counter, and second commands protected by a MAC code function of the session key. An update of the sequence counter in non-volatile memory of the slave at each new establishment of a secure channel renders the pre-generated batch obsolete due to a new session key. In order to allow a replay of the batch, the invention provides for temporarily storing each update value of the counter in volatile memory, and of overwriting the current value in non-volatile memory during predefined events, including the attainment by a test counter of a maximum number of replay.
公开号:FR3027176A1
申请号:FR1459800
申请日:2014-10-13
公开日:2016-04-15
发明作者:Jean-Philippe Vallieres；Sebastien Nerot
申请人:Oberthur Technologies SA；
IPC主号:

专利说明:

[0001] FIELD OF THE INVENTION The present invention relates to the field of communications and more particularly that of communications between a master device, for example a server, and a slave device, for example a client.
[0002] BACKGROUND OF THE INVENTION Two communicating entities define a communication layer for exchanging messages. This communication layer is often defined using a protocol known as secure channel (or "Secure Channel" in English terminology), to offer different levels of protection of communications and data, for example in terms of entity authentication, data integrity and confidentiality. Such a protocol is widely used in the chip card industry to exchange data in a master-slave relationship. The master initiates the communication channel then the communication by sending commands to the slave, the slave only responding.
[0003] As an illustration, the smart card, and in general any secure element (SE for "Secure Element"), integrated circuit card (ICC), universal (UICC) or embedded (eUICC), can officer as slave, for example in "server" mode in a client / server context. A remote device can play the role of master and therefore of "client" in a client / server context.
[0004] To achieve a high level of security, the secure channel protocols implement security mechanisms that rely on one or more dynamic variables, that is to say on variables that change over time. The commands and messages exchanged between the master and the slave are then generated from this or these dynamic variables, possibly via session keys, thus preventing them from being replayed if the dynamic variables (and therefore the session keys in the example) have evolved. For example, these dynamic variables can include risks exchanged between the master and the slave in an authentication process (challenge-response type), and / or include a sequence counter which is incremented at each new establishment of a channel. secure between the two entities. This is for example the case in SCP02 and SCP03 protocols (for "Secure Channel Protocol" 02 and 03) widely used in the chip card industry and defined in the GlobalPlatform standard. In these protocols, the dynamic variables are used to generate one or more session keys used to authenticate and / or encrypt the exchanged data and to generate a message authentication code (or MAC for "Message Authentication Code"). Orders are thus secured or protected. In many of these secure channel protocols, the different secure commands sent by the master (same for secure responses sent by the slave) are chained so that the generation of the N + 1 command (response) requires that the previous command (response) N is valid. For example, the authentication code of a message (command or response) may be of the CBC-MAC ("Chained Block Ciffering") type in which the initialization value is the CBC-MAC of the previous message.
[0005] Similarly, the CBC data encryption may involve an internal counter which is incremented for each new command, so that in the same secure channel, the secure commands are different even if the data they contain are the same. The purpose of chaining is to ensure that secure commands (responses) are sent and processed in a planned order. It also allows for easier detection of unplanned commands (responses) (eg a reset command), for example sent by an attacker. The explanations below are based primarily on examples in which the commands are chained. However, the present invention is not limited to such linked commands. Some of the secure channel protocols can pre-generate secure commands, without requiring any previous commands or responses at this stage. To do this, the entity in question, generally the master, has mechanisms enabling it to predict (or simulate or reproduce) the behavior of the other entity, here the slave, in particular the evolution of the dynamic variables and the answers that the slave should generate. We are talking about a predictive mode of the secure channel protocol. For example, the data necessary for the predictive mode may comprise one or more secret keys shared between the master and the slave, from which the session keys are generated; dynamic variables, typically an incremented sequence counter for each new establishment of a secure channel, also for generating the session keys; also the algorithms for predicting (or pre-generating) pseudorandom values used during authentication exchanges (challengeresponse). The predictive mode is often used by the master device to pre-generate a batch (or set or set or series) of secure commands, usually chained, which are packaged into a file or "script" or "batch" as shown on the Figure 1. In the batch of this figure, the first command to initiate and establish a secure channel, the next command, which is secure, contributes to an authentication mechanism, then the other 3 secure commands aim to to pilot particular treatments within the slave device. Figure lA shows another example of a batch of secure commands without an authentication process. The SELECT APPLICATION command is optional because it can be performed in a decorrelated manner, before the batch of the STORE DATA secure commands. In addition, it does not include any indication on a possible security of the communication channel. Thus, the first STORE DATA secure command (identifiable by the block number = 0 contained in parameter P2) is the first command indicating the establishment of a secure channel, since its CLA field contains an indication that it is secure. Other STORE DATA commands are also secured and chained. In practice, command scripts are used when the master and slave devices are relatively remote and one or more intermediate entities, or third-party devices, are interposed with each other, as shown in FIG. third parties in direct link (for example implementing the SSL protocol - for "Secure Sockets Layer" or secure socket layer) with the slave device interacts with the latter on behalf of the master device. By way of example, the third-party device may be an application (and / or system) implemented in a terminal in which the slave device (SE, UICC, etc.) is embedded, in particular a midlet (application) responsible for wake up the slave device before communicating with him. Alternatively, the third-party device may be any machine in a communication network, i.e. a transport intermediate. The third party device is not necessarily a trusted device. In particular, it does not have the data ensuring the protection of the secure channel (in fact secure commands of the batch), in particular the shared secrets, the session keys, the algorithms used, etc. In practice, the third party device is responsible for transferring the commands and any secure responses, because it does not know these data ensuring the protection of the secure channel and is therefore unable to process the commands and responses thus transferred. In addition, it can check a general status of order processing to determine if they can be processed successfully, and can return to the master device, at the end of processing, a general status message indicating for example the number of orders transmitted. The master device can thus make decisions from the received general status message. In the context of the command batches, the third-party device can play a role of timer of the commands, by which it decides to send the commands to the slave device at a convenient moment, for example at times when the communications with the slave device are in low numbers. Thus, the master device may only receive the general status message 30 days after sending the command script to the third party device. In addition or alternatively, the transfer of commands can be done on a regular basis, for example similar to the CRON or CRONTABLE techniques of a Unix system. The predictive mode of a secure channel protocol is used during chip production steps (slave device) to speed up the production process. Indeed, the pre-generated orders can thus be sent in batch, minimizing the order processing time.
[0006] Another use of the predictive mode relates to the components (cards, SE, eUICC) deployed, for example SIM cards of a telephone operator or secure elements equipping remote reading devices (machine-to-machine). In this case of deployment, it is difficult to establish a continuous communication link (because of a firewall, DMZ demilitarized computer zone, etc.). It may then be advantageous to transmit the batch of commands to a third party device near the slave component. OTA ("Over-The-Air") methods are particularly known in the mobile industry where an operator (the master) pre-generates a series of commands for the SIM cards (slaves) of the subscribers in order to program / reconfigure them . This series of commands may be issued at any time to a third party device, typically the subscriber's terminal, responsible for transmitting the commands to the target SIM card. The diagram of FIG. 3 illustrates a conventional use of a batch of commands in the system of FIG. 2. In this example, the master device generates a batch of commands to be sent to the slave device, for example that of FIG. which the command batch includes a command, called the first command (for example the initialization command INITIALIZE UPDATE according to SCP03), indicating the establishment, with the slave device, of a communication channel secured by at least one key of session key (for example the S-MAC key according to SCP03), this session key being dependent on a current value of a dynamic variable shared between the master device and the slave device, and includes at least one command, said second command , secured (or protected) by a message authentication code calculated using the session key. This generation implements the predictive mode of the secure channel protocol, involving the update of the shared dynamic variable (the sequence counter in SCP03).
[0007] Thus, the third party device that receives from the master device the batch of commands to be sent to the slave device, plays it so as to send, to the slave device, said commands of the batch sequentially, command by command, as long as no error is detected. As shown in the figure, playing the batch of commands amounts to looping each order so that it is sent and a response is returned (usually a run status message). The secure channel is closed as soon as an error occurs. An example of an error is the expiration of a timer (timer out) after sending a command that has remained unanswered, or an error message returned by the slave device. For its part, the slave device receives commands sequentially, that is to say, without being aware of the existence of a batch or command script played by the third party device. Thus, the slave device receives, from the third-party device, at least one command, called the first command, indicating the establishment of a secure communication channel by at least one session key; calculates an update value of the one or more dynamic variables (in particular the sequence counter) from a current value of the dynamic variable (s) stored in non-volatile memory; generates the session key from the calculated update value. Then, in view of the sequential (loop) sending of the commands, the slave device also receives, from the third party device, at least one command, called the second command, secured by a message authentication code (type C-MAC according to SCPP03 ); and verifies the message authentication code using the session key before executing said second command. Generally, the slave device returns an execution status message (sometimes data) in response to each processed command. Different situations can lead to the third-party device issuing a failed status of the execution of the batch of commands, and thus to closing the secure channel: no response from the slave device to the commands, error message received from the device slave, power off the slave device for example due to lack of battery, etc.
[0008] When the master device receives such a failure status message, it may wish to execute the same commands again, while the secure channel has been closed. However, the dynamic variables from which the security mechanisms of the secure channel are defined have evolved: the session keys of a new secure channel will be different from those of the closed secure channel. Thus, it is conventional for the master device 30 to generate, in predictive mode, a new batch of the same commands, but by calculating new authentication codes and by re-encrypting the command data using new session keys. predicted. However, this situation is not satisfactory because, for the batch of commands to be successfully executed, new connections, new cryptographic (and therefore expensive) processes are necessary for the master device to generate the new batch of commands. This decreases the ability of the master device to handle other requests or standard operations. Furthermore, in view of the fact that the processing of the batch of commands by the third device and the slave device can be decorrelated, in time, from the sending of the same batch by the master device, the latter is informed late. of failure, thus leading to a significant loss of time (sometimes in days) for the master device. This waste of time can for example be detrimental if updates are to be made, batch of orders, in a fleet of deployed components. Indeed, this situation reduces the capabilities of the master device to program or quickly control the fleet of components deployed geographically. This damage is all the more important because the reasons for the failure of the execution of the batch of orders can be minimal and sometimes very punctual: attempted attack by a malicious person, disruption (for example interferences) on the link of 10 communication between third party devices and slave, etc. The present invention aims to solve all or part of the disadvantages mentioned above. SUMMARY OF THE INVENTION In this context, the invention proposes a communication method comprising, at the level of a slave device, the steps mentioned above, and furthermore the following steps: incrementing, of a positive increment or negative (in which case it is also referred to as decrementing), a test counter upon receipt of the first command indicating the establishment of a secure communication channel; and overwriting the current value of the dynamic variable in non-volatile memory with the calculated update value when the test counter reaches a threshold value. In other words, register the calculated update value (of the dynamic variable) in non-volatile memory as the new current value of the dynamic variable when the test counter reaches a threshold value. Thanks to the use of a test counter which delays the actual update of the dynamic variable in non-volatile memory (and therefore before any new secure channel requires new data to protect the secure channel, for example new session keys, and therefore before the batch of commands is obsolete), the slave device 30 allows the third device to make several tests of the set of commands to be executed by the slave device. Indeed, the session keys of the secure channels established during these replay are the same. This plurality of tests notably makes it possible to overcome possible attacks and / or communication disturbances in order to execute the entire batch of commands.
[0009] Thus, the replay of a batch of commands by the third-party device is possible, which reduces the use of the master device for this full execution. The number of connections, the amount of cryptographic processing required by the master device and the time required for this complete execution are therefore reduced. In addition, the master device is no longer available to process other commands.
[0010] The validation of the update of the shared dynamic variable by switching the update value as a new current value in nonvolatile memory is also known by the term "commitment" in the English terminology. Symmetrically, the invention also provides a communication method 5 comprising, at a third-party device, the steps mentioned above, and further the following step: replay the batch of commands as the third device does not does not receive, from the slave device, an indication of an update of the current value of the dynamic variable by the slave device. In other words, as long as the third device does not receive, from the slave device 10, an output event of a replay loop of the batch of commands. As will be seen later, the indications can be indirect, that is to say implicit to transmitted information. The invention allows a controlled replay of a batch of secure commands, by taking into account an indication of the slave device on the effective update or not of the shared dynamic variable from which the protections are established. secure channel. This behavior of the third party device thus allows a slave device to use a test counter as mentioned above, in order to reduce the use of the master device to successfully execute the entire batch of commands.
[0011] Correspondingly, the invention also relates to a processing device, for example a smart card, comprising a non-volatile memory storing a current value of a dynamic variable, and a processor configured to: receive, from a third-party device, the least one command, said first command, indicating the establishment of a secure communication channel by at least one session key; calculate an update value of the dynamic variable from the current value stored in non-volatile memory; generate the session key from the calculated update value; receiving, from the third party device, at least one command, said second command, secured by a message authentication code; and verifying the message authentication code using the session key before executing said second command; characterized in that the processing device further comprises a test counter, and the processor is further configured to: increment the test counter upon receipt of the first command indicating the establishment of a secure communication channel ; and overwriting the current value of the dynamic variable in non-volatile memory with the calculated update value when the test counter reaches a threshold value.
[0012] Symmetrically, the invention also relates to a processing device comprising a processor configured to: receive, from a master device, a batch of commands to be sent to a slave device, the batch of commands including a command, said first command, indicating the establishment, with the slave device, of a secure communication channel by at least one session key dependent on a current value of a dynamic variable shared between the master device and the slave device, and at least one command, said second command, secured by a message authentication code calculated using the session key; 10 to play the batch of commands so as to send, to the slave device, said commands of the batch sequentially, command by command, as long as no error is detected; characterized in that the process is further configured to: replay the batch of commands as long as the processing device does not receive, from the slave device, an indication of an update of the current value of the dynamic variable by the slave device. Also, the invention proposes a system comprising a slave device as defined above, a third-party device as defined above, and a master device configured to generate and send the batch of commands to the third-party device.
[0013] The invention also relates to a computer program product comprising instructions adapted to the implementation of each of the steps of one of the methods described above when said program is executed on a computer. The devices and computer program product according to the invention have advantages similar to those previously described in connection with the methods.
[0014] Other features of the methods and devices according to embodiments are described in the dependent claims, essentially using process terminology, transposable to the devices. In one embodiment, the step of calculating an update value includes recording the calculated update value in a volatile memory of the slave device. This provision ensures that the current value of the dynamic variable is not modified by the value or values calculated for its update. Thus, it remains possible to establish one or more secure channels using the same current value of the dynamic variable, remained unchanged in non-volatile memory. As a result, the replay by the third party device of a batch of commands requiring the establishment of such a secure channel is made possible and is guaranteed. In another embodiment, the current value of the dynamic variable in non-volatile memory is overwritten in non-volatile memory with the update value calculated when the last secure command of all the second secure commands (for example via an indicator in the relevant command) includes a validated message authentication code and is executed successfully. This situation corresponds to the complete execution of the secure orders of the lot. The secure channel is no longer necessary and can be closed, in which case the dynamic variable (s) must be updated in order for the next secure channels to be established with new security data (session keys for example). . This situation is an example of an exit event from the replay loop, because such a replay proves useless given the successful execution. In a particular embodiment, the method (on the slave device side) further comprises the following step: transmitting, to the third party device and in response to said last secure command, a message including an indication that the execution of said one or more second orders of the batch has been successfully completed. This indication allows the third party device to be indirectly informed of the actual update of the dynamic variable (the sequence counter in SCP03) in nonvolatile memory of the slave device. In yet another embodiment, the current value of the dynamic variable in non-volatile memory is overwritten in non-volatile memory with the update value calculated when a said second command whose message authentication code has been verified with success leads to an error or exception of execution of this second command, such as when a host cryptogram (authentication procedure described later) is declared invalid during an EXTERNAL AUTHENTICATE command (in SCP03) or when the decrypted command turns out to be wrong. These situations are examples of an exit event of the replay loop, because in these situations the replay of the same command will lead to the same error: the replay of the batch of 25 secure commands is therefore useless. This configuration forces the effective update of the dynamic variable in nonvolatile memory (commitment or failover), and hence now makes it impossible to replay the command batch, because the execution error or exception translates an intrinsic error to the secure commands. batch, which can not be corrected by a simple replay, but by the master device by generating a new batch of the same commands. The provision proposed here thus makes it possible to avoid a loss of time related to the replay of an intrinsically erroneous batch of commands. In a particular embodiment, the method (on the slave device side) further comprises the following step: transmitting, to the third device and in response to said second command leading to an execution error or exception, a message including an indication of the execution error or exception despite a successfully verified message authentication code. This indication also allows the third-party device to be indirectly informed of the actual update of the dynamic variable (the sequence counter in SCP03) in the nonvolatile memory of the slave device.
[0015] It will be understood from these various provisions that the commitment or switching of the dynamic variable (the sequence counter in SCP02 or SCP03 for example) takes place only when one of the replay loop output events (reaching the counter threshold value, end of the batch of orders, detection of an erroneous order in the batch despite its authenticity and integrity) occurs. Out of such events, the batch of commands can be replayed if an unexpected error has occurred, as long as the number of allowed tries is not reached. In one embodiment, the test counter is reset to a default value when the current value of the dynamic variable in nonvolatile memory is overwritten with the calculated update value. For example, this default value, stored in EEPROM memory, can be modifiable in time. This provision makes it possible to reconfigure the system for a new series of replay of a new batch of commands, the commands for this new batch having to be secured using the dynamic variable as effectively updated (this is ie with the new current value). In a particular embodiment, the step of overwriting the current value in non-volatile memory with the calculated update value and the step of resetting the test counter are performed before the step of generating the session key from the calculated update value.
[0016] This arrangement guarantees a strong security of the method according to the invention, by reducing the risks that a malicious person can replay indefinitely a set of operations by the slave device, because the commitment or switching of the dynamic variable is carried out at the earliest in the initialization procedure of the secure channel. In particular, the recording step may precede that of incrementation.
[0017] In a particular embodiment, the step of overwriting the current value in non-volatile memory with the calculated update value and the step of resetting the test counter are performed in an atomic step. This arrangement makes it possible to significantly reduce the risks of a desynchronization between the dynamic variable and the test counter, and consequently the possibilities for a malicious person to replay the batch of orders indefinitely. In one embodiment, said first command is a second command secured by a message authentication code. An indication of the implementation of a mechanism for securing the channel (encryption and MAC by key) can be provided in a non-secure and therefore readable field (for example the code CLA in SCP03) of the header of the command. , used to trigger the generation of session keys to decrypt the command and check the MAC code. In an embodiment relating to the third-party device, receiving the indication of an update (effective) of the dynamic variable (shared) by the slave device comprises receiving, from the slave device, a current value of the dynamic variable and comparing the current value received with a local value of the dynamic variable. The third-party device can thus directly check whether the slave terminal has publicly updated its dynamic variable by comparison with the last (local) value of which it is aware.
[0018] In particular, the current value of the dynamic variable can be received by the third party device in a response of the slave device to the first command. This provision builds on existing protocols without modifying them, while requiring little additional processing for the third-party device. Indeed, it is conventional that the sequence counter (i.e., a shared dynamic variable in the case of SCP02 and SCP03) is returned in response to the initialization command (INITIALIZE UPDATE in these same protocols). , allowing the third-party device, by simple comparison with the last value of the counter of which it is aware, to effectively determine whether an actual commitment (commitment) of the sequence counter has taken place in the interval or not. In another embodiment, the indication of an update of the current value (thus making it possible to decide the replay of a current batch of commands) includes an indication that the execution of said second command (s) batch by the slave device has been successfully completed. In another embodiment, the indication of an update of the current value includes an indication that the slave device executes a second batch command whose message authentication code has been set. been verified successfully led to an error of this second order. As discussed above, this configuration includes the case where the verification of the host cryptogram of the EXTERNAL AUTHENTICATE (SCP03) command failed despite valid MAC code. Preferably, the three indication examples defined above for the third party device (current value, indication of success or of an error despite a valid MAC code) are the only replay loop output events from which the Third-party device knows that it can not replay the batch of commands. Indeed, as explained above, the shared dynamic variable has, in these cases, been updated, so that the MAC authentication codes or even the ciphers of the commands in the current batch are now out of sync with the new keys of the current batch. session. In another embodiment, receiving the indication of an update (effective) of the dynamic variable by the slave device comprises receiving, from the slave device, an error message (for example 0x6982 in SCP03 of GlobalPlatform) in response to a said second command immediately subsequent to the first command, the error message indicating an error message authentication code of said second command immediately subsequent to the first command. In this configuration, the third-party device considers that if, from the first command protected by a MAC code (based on the dynamic variable, via the session keys), the MAC code is erroneous (error message 0x6982 in the GlobalPlatform standard) , 3027176 12 then it is likely that the session keys (and not consequent the dynamic variable) are not those provided for MAC codes generated beforehand in the batch of commands. It is indeed likely that the dynamic variable has been incremented on the side of the slave device resulting in a desynchronization with the command batch previously predicted. It will be understood that this arrangement is not optimal because a MAC code error can also result from a disruption of the communication channel. In one embodiment, the message authentication codes of several second commands are chained, in particular in that the calculation of the MAC authentication code of a second following command depends on the MAC code of a second previous command. . This arrangement secures the execution of the batch of commands against attacks aiming at inserting unplanned commands or disordering the commands defined in the batch. BRIEF DESCRIPTION OF THE FIGURES Other features and advantages of the invention will become apparent in the following description, illustrated by the accompanying drawings, in which: FIGS. 1 and 1A illustrate examples of batches or batches of commands pre-generated; Figure 2 schematically shows a system in which embodiments of the invention are implemented; Figure 3 illustrates a typical use of a batch of commands in the system of Figure 2; FIG. 4 illustrates an example of hardware architecture of each device constituting the system described with reference to FIG. 2; Figure 5 schematically illustrates the conventional exchanges in accordance with the SCP03 protocol defined in GlobalPlatform; FIG. 5A schematically illustrates exchanges in a predictive mode of the SCP03 protocol; Figure 5B schematically illustrates exchanges in a predictive mode of a batch of commands without an authentication procedure; - Figure 6 illustrates, on the same diagram as Figure 3, the possibility of replay of a batch of commands according to embodiments of the invention; FIG. 7 illustrates, in the form of a flow chart, general steps of an embodiment of the invention on the side of the slave device; FIG. 8 illustrates, in the form of a flow chart, general steps of an embodiment of the invention on the side of the third party device; FIG. 9 illustrates, by repeating the diagram of FIG. 5A, exchanges of one embodiment of the invention based on the predictive mode of the SCP03 protocol; FIG. 9A illustrates, by repeating the diagram of FIG. 5B, exchanges of one embodiment of the invention of a batch of predicted commands without an authentication procedure; and FIG. 10 illustrates the delay effect of effectively updating the sequence counter in nonvolatile memory during an implementation of the invention. DETAILED DESCRIPTION OF THE INVENTION Figure 2 schematically illustrates an exemplary system in which embodiments of the present invention may be implemented. The system 10 comprises a master device 12, for example a server of a telephone operator, and a slave device 14, for example a SIM card, which the telephone operator wishes to update. The slave device 14 is for example embedded in a mobile terminal, acting as a third device 16 in exchanges between the master devices 12 and slave 14. Other intermediate devices (not shown) between the master devices 12 and slave 14 may exist in the context of the invention. In this example, the telephone operator's server is said to be "master" because it initiates exchanges with the SIM card, which is therefore "slave". To perform these exchanges, the master device initiates a secure channel, for example according to the SCP03 protocol, then sends a series of commands to the SIM card. Other protocols and degraded modes of SCP02 and SCP03 plan to avoid a procedure for initialization of the secure channel, and allow the direct sending of secure commands. In this case, the first secure command indicates that a secure channel is implicitly established, usually from shared secrets between the master and the slave. The link between the master device 12 and the third device 16 may be wired 25 (Ethernet connection) or wireless (mobile network). In the example where the third device 16 is a terminal carrying a SIM card 14, the communication link between these two entities is of contact type. Of course, non-contact (wireless) variants can be envisaged. Figure 4 illustrates an example of hardware architecture of each device constituting the system described with reference to Figure 2.
[0019] In this example, the device, that is to say the SIM card 14 or the terminal 16 or the server 12, comprises a communication bus to which are connected: a processing unit or microprocessor noted CPU (acronym Central Processing Unit in English terminology); one or more non-volatile memories, for example ROM (acronym for Read 35 Only Memory in English terminology) that can constitute a medium within the meaning of the invention, that is to say that can comprise a computer program comprising instructions for the implementation of a method according to one embodiment of the invention. This non-volatile memory can also be an EEPROM (acronym for ElectricallyErasable Read Only Memory in English terminology) or a flash memory. In particular, this non-volatile memory of the slave device 14 stores the current value of the shared dynamic variable (s), for example the sequence counter in the case SCP02 or SCP03 mentioned later. a random access memory or volatile memory or memory for example RAM 5 (acronym for Random Access Memory in English terminology) including registers adapted to the recording of the variables and parameters created and modified during the execution of the aforementioned program ; during the implementation of the invention, the instruction codes of the program stored in ROM memory are loaded into RAM memory for execution by the CPU processing unit; A communication interface adapted to transmit and receive data, for example via a telecommunications network or a read / write interface of a secure element; an input / output I / O interface (for Input / Output in English terminology), for example a screen, a keyboard, a mouse or other pointing device such as a touch screen or a remote control; this I / O interface allows the user to interact with the system during the implementation of the method via a graphical interface. The communication bus allows communication and interoperability between the various elements included in the equipment or connected to it. The representation of the bus is not limiting and, in particular, the processing unit is able to communicate instructions to any element of the equipment directly or via another element of this equipment. Figure 5 schematically illustrates the conventional exchanges in accordance with the SCP03 protocol defined in GlobalPlatform. It should be noted that in the aforementioned predictive mode, the set of commands sent by the master device in this FIG. 25 can be grouped into a batch of commands played by a third device, for example a terminal embodying a card-type slave device. SIM. As shown schematically in Figure 1, these exchanges may include a first part dedicated to the establishment of a secure channel, involving a authentication procedure of the type "Challenge-Response" well known. Although not illustrated, these commands to a target application of the slave device occur after an initial command to select said target application, typically a widely known SELECT command. In a variant, no SELECT command is provided, an application of the slave device 14 that can be selected by default (that is, as long as no SELECT command for another application is received) at the time of voltage of the slave device 14. Thus, the master device 12 generates, in step 500, a host challenge (random or pseudo-random) that it transmits to the slave device 14 during the step 502, to the using an INITIALIZE UPDATE command.
[0020] When this command is received, the slave device 14 updates, at step 504, its sequence counter (on three bytes) by incrementing (the current value is incremented in non-volatile memory), and then calculates, at step 506, a function map challenge of the sequence counter and an identifier (AID) of an application selected in the map. The generation of the card challenge is generally pseudo-random and predictive (for the master device 12 in the case of a predictive channel). In step 507, the slave device 14 generates the session keys (in particular described in section 6 of the GlobalPlatform standard) for the secure channel, notably using the current value of the sequence counter, the host and card, as well as one or more static secrets shared between the master and slave devices. In step 508, the slave device 14 calculates an authentication cryptogram for the card, a function of the host and card challenges, as well as a (shared) constant. For example, the cryptogram generation function may be the S-MAC algorithm based on one of the generated session keys.
[0021] The slave device 14 sends back to the master device 12 the card challenge, the card cryptogram, as well as the current value of the sequence counter. This is step 510. Upon receipt of this data, the master device 12 checks (511) the status of the response before continuing, indicated for example in the optional argument. If the status is positive (field SW = 9000), the master device 12 generates, in step 512, the session keys in a manner similar to the slave device 14. Then, the master device 12 calculates and verifies the card cryptogram, by applying the same (shared) algorithm as that of the slave device 14. This is the step 514. In the step 516, the master device 12 calculates an authentication cryptogram 25 for the host, according to the session keys (They also depend on host and map challenges, the card challenge being also a function of the sequence counter in predictive mode), as well as a (shared) constant. For example, the cryptogram generation function may be the S-MAC algorithm based on one of the generated session keys. This host cryptogram is sent to the slave device 14 by an EXTERNAL AUTHENTICATE command, which is protected in integrity and authenticity by the addition of a MAC authentication code calculated on the host cryptogram, using a key session dedicated to MAC. Sending corresponds to step 518. In step 520, the slave device 14 checks the MAC code, then the received host cryptogram to confirm the creation of the secure channel (acknowledgment response 522). The master device 12 checks the status of the received response. In parallel or after positive verification of the status of the response, in step 524, the master device 12 generates and optionally digit (using the session keys) one or more commands. In addition, a security MAC code is calculated for each of them and then added to them. The encryption of the commands and their MAC codes are generally, but not necessarily, chained in the sense that each of them depends on the previous one (and thus initially the MAC of the EXTERNAL AUTHENTICATE command). Of course, in the predictive mode, these commands, including their encryption and their MAC code, are predicted and thus generated before the establishment of the secure channel 5. Step 526 schematically shows the successive sending of these commands and the reception, by the master device 12, of their responses. For example, a command may be the STORE DATA command defined in GlobalPlatform for storing new data in nonvolatile memory of the slave device 14.
[0022] For each of these secure commands, the slave device 14 checks the MAC code (step 528), then decrypts it (step 530) before executing it. In response to this execution, it returns a positive acknowledgment (OK, the SW field is 9000) or an error message (NOK), which is processed by the master device (step 532), or even data encrypted and protected by MAC in which case the master device 12 checks their integrity (by the MAC code) 15 and proceeds to their decryption (534). FIG. 5A illustrates a realization of the predictive mode for SCP03 leading to the sending of a batch of commands to a third device 16. It should be noted that in the predictive mode, the master device 12 does not take into account the elements of the response 510. Indeed, it locally holds an image of the variables and 20 values held by the slave device 14, for locally calculating the card challenge, the card cryptogram in knowledge of the new value of the sequence counter. In the example shown, these different processes that the master device 12 performs in a predictive manner are performed before transmitting the batch (batch) commands: 25 recovery of the public value of the shared sequence counter with the target application, pseudo generation - Random host and card challenges, generation of session keys, generation of INITIALIZE UPDATE and EXTERNAL AUTHENTICATE commands, with its MAC code, generation of other secure commands to form the batch of commands. The third device 16 then plays a simple intermediate role: the latter receives, from the master device 12, only the batch of commands to be played on its behalf with the slave device 14. It can check the received response status to determine whether the execution of the lot must be aborted. As a variant, it can simply retransmit all the responses to the commands that it transmits successively. At the end of the execution of the batch of commands, the third device 16 may send a general status message to the master device 12, for example to indicate the number of commands sent and whether the execution of the whole batch has been completed. performed successfully or not. As a variant, no general status message is sent, the verification of the status (success or failure) being able to be requested during a subsequent command.
[0023] In these embodiments of SCP03, the STORE DATA commands are secured, that is to say provided with a chained MAC code. In a degraded variant, the SCP03 protocol can be used only for the authentication process (INITIALIZE UPDATE and EXTERNAL AUTHENTICATE commands) so that the STORE 5 DATA commands generated in step 524 are neither encrypted nor secured by a MAC code. Thus, only the EXTERNAL AUTHENTICATE command is secured by MAC. It also indicates, via parameter P1 (defined in Global Platform), that subsequent commands are not secure. In embodiments without authentication processes, the commands INITIALIZE UPDATE and EXTERNAL AUTHENTICATE are not provided, and the batch of commands starts directly with secure commands, type STORE DATA (see Figure lA where the SELECT APPLICATION command is optional. because it can be done in a decorrelated way, before the transmission of the STORE DATA secure commands). This is made possible by the prediction of dynamic variables allowing the master and slave devices to have the same session keys without even exchanging messages. The command securing information is, for example, entered in the parameter P1 of the first STORE DATA command (identifiable by the parameter "block number equal to 0 for this command) thus received, making it possible to trigger the steps 504-508 on the device slave 14. See Figure 5B in this sense. In the configuration of this Figure, the host challenge may be (pseudo-random) predictable, allowing the slave device 14 to obtain it by an internal process. Alternatively, it can be obtained during a previous operation (not shown) with the master device 12. The SCP02 protocol also defined in GlobalPlatform is distinguished from the SCP03 protocol of FIG. 5 in that the sequence counter is not incremented upon receipt of the INITIALIZE UPDATE command, but upon receipt of the EXTERNAL AUTHENTICATE command. The present invention is part of a predictive mode of a secure channel protocol, for example of the SCP02 or SCP03 protocol. In the known techniques, a batch of pre-generated commands can be played only once, leading to many additional costs, mainly for the master device 12. In order to allow a replay of this batch of commands, the invention plans to use a replay or test counter. The number of replay is preferably reasonable, especially to prevent a malicious person to infinitely test a sequence (batch) of commands. In this case, this number is limited by a threshold value or "replay limit", as illustrated hereinafter. The test counter makes it possible to delay the concrete incrementation of the sequence counter, that is to say its effective updating in non-volatile memory. Thus, during the use of the test counter, the current value of the sequence counter serving as a reference for the establishment of a secure channel remains unchanged in non-volatile memory, which makes it possible to replay the same batch of commands. secure with the predicted session keys of this secure channel. Only when this value in non-volatile memory is updated (modified), the batch of commands becomes obsolete, requiring to request the master device to obtain an updated batch to match the keys of sessions predicted from the new current value of the sequence counter. As defined above, a slave device 14 according to the invention increments a test counter upon receipt of a command, said first command (including an initialization command INITIALIZE UPDATE in SCP02 or SCP03), indicating the establishment of a secure communication channel; and overwrites the current value of the dynamic variable in non-volatile memory with the calculated update value when the test counter reaches a threshold value, i.e., it records an update value computed in non-volatile memory as the new current value of the dynamic variable (for example the sequence counter used to secure the communication channel) when the test counter reaches a threshold value.
[0024] By using this test counter which delays the commitment (commitment) of the update value as a new current value of the dynamic variable in non-volatile memory, the same commands (secured by the current value of the dynamic variable) can be replayed. Thus, the third device 16 can replay the batch of commands as long as the slave device has not updated the current value of the dynamic variable in non-volatile memory, that is to say as long as it receives not, the slave device 14, an indication indicating an update of the current value of the dynamic variable (the sequence counter) by the slave device. As will be seen later it is appropriate for example for the third device 16 to be able to analyze the response status of the slave device 14 in order to detect certain status corresponding to situations where the slave device has 25 concretely set update the current value of the sequence counter because a replay of the batch of commands is not appropriate. FIG. 6 illustrates, on the same diagram as FIG. 3, the possibility of replaying a batch of commands by the third device 16, represented in this figure by a loop (bold arrow) as long as the limit of the number of the tests counted by the slave device 14 30 is not reached (in which case an indication is transmitted to the third device 16) or that an exit event (indicating that a replay of the batch of commands is not useful) is realized . In this configuration, the occurrence of an unexpected event (timer out, reset, disruption of the communication channel, etc.) does not lead directly to soliciting the master device 12 for the generation of a new batch of commands. Here, the batch of 35 commands for which the unexpected event occurred can be replayed if it is not an "exit" event. If this event is punctual, the new replay of the batch of commands should lead to it being played in its entirety. It is thus seen that one avoids soliciting the master device, when uncontrolled events occur.
[0025] In the approach proposed here, the third device 16 thus has the ability to replay, up to a certain limit, a batch of commands when it receives, from the slave device 14, an error notification. on the commands played, that is to say, an exit event of the replay loop.
[0026] When said limit of the number of replay is reached, the slave device 14 indicates it (explicitly or implicitly) so that the third device 16 does not replay the current batch of commands, but requests the master device 12 to generate a new batch of updated commands (if the current batch could not be executed normally). Orders for the new lot may be similar to those of the current lot; the difference being that the encryption and computation of the MAC codes for the secure commands are now based on a new value of the sequence counter, in SCP02 or SCP03. Of course, when the execution of the entire batch of orders has been successful, it is expected that the replay is not possible, to avoid any analysis by a malicious person. A status indicating the successful execution of the batch of commands 15 thus constitutes an exit event of the replay loop. Other exit events are considered below to avoid a replay when it is useless. This is for example the case when a secure command, integrity and authentic (that is to say with a valid MAC code) leads to an execution error or exception. In these cases, the slave device 14 only has to update the sequence counter (the dynamic variable) in non-volatile memory, making the current batch of commands obsolete. The third device 16 is notified of this situation thanks to the response statuses it receives from the slave device 14. FIG. 7 illustrates, in the form of a flow chart, general steps of an embodiment of the invention on the slave device 14.
[0027] The method of the figure starts with an initialization phase (steps 700 to 704) that can occur during customization of the slave device, typically a smart card or secure element. During this phase, a test counter is created in non-volatile memory, and initialized to a default value, for example 10, in step 700. Then, in step 702, a limit threshold value of the number of tests (and therefore replay) is defined and stored in nonvolatile memory, for example 10. In this embodiment where the test counter is initialized to the maximum number of tests allowed, this test counter will be decremented for to reach, finally, the value 0, which is easily detectable because at that moment, the passage of the counter from 0 to -1 requires to modify all the bits (for example for a counter on 32 bits: 00000000 -> FFFFFFFF if four bytes). Of course, other embodiments can initialize the counter to 0 and increment it to the limit threshold value equal to 10. At step 704, the dynamic variable (s), typically the sequence counter, are initialized. For example, the sequence counter is initialized to 0. It may be during this step 704 that the dynamic variable and any other parameters (for example a secret) are shared between the slave device 14 and the master device 12 for enable the implementation of the predictive mode of secure channel protocols. Following its customization, the slave device 14 is put into service where it is waiting for the establishment of a new secure channel. This is for example the receipt of an INITIALIZE UPDATE command in the case of SCP02 or SCP03 shown in FIG. 5A. This is the receipt of the first command (for example STORE DATA) secured in the example of Figure 5B. This is step 706. When such a command is received, steps 708 and 710 consist in verifying that the test counter and the maximum number of tests are not both 0, to which 10 cases none. secure channel can not be established (step 712) and the process terminates. In the general case, the maximum number of tests is not zero. Thus, as long as the test counter (in a mode where it is decremented) is not zero ("no" output of the test 708), the test counter is decremented in step 714, followed by the step 716 of updating the dynamic variables required for the secure channel, that is, calculating an update value of the one or more dynamic variables (including the sequence counter) from a value current or the dynamic variables stored in non-volatile memory. The update value or values of these dynamic variables are then stored in volatile memory, ensuring that their current values remain unchanged, and thus adapted to a replay of the same batch of commands.
[0028] The slave device 14 then processes the received command in a conventional manner, as well as subsequent secure commands as received from the third party device 16. These operations on the secure channel are schematically represented by step 718, and are described above with reference Figures 5 to 5B. The execution of the secure commands of the current batch leads to two main situations, and a situation treated in a particular way here. As shown in the figure at step 720, it is determined whether the execution of the batch of secure commands has proceeded well ("normal" output in the test 720) or if an unforeseen event has occurred ("unexpected" output In the 720 test). Such an event may correspond to a transmission error of a secure control of the batch (detectable error through the MAC code accompanying the command). In this case, the secure channel is closed by sending an error message to the third party device 16 (step 722), before the slave device 14 waits for a new command for a new secure channel. The "normal" execution of the secure command batch occurs when the slave device 14 has received all the secure commands, with valid MAC authentication codes. The last command may include an indication of the end of secure commands (a binary flag may be provided for this purpose in the command, the field P1 may indicate that the following commands are no longer secure), allowing the slave device 14 to detect the end of secure orders.
[0029] Any other means for the slave device 14 to identify the last secure command may be provided. Normal execution of all the secure commands constitutes an exit event of the replay loop, leading to the closing of the secure channel. In this case, the slave device 14 stores the calculated update value (which is in volatile memory at this time, because of the step 716), in non-volatile memory as the new current value of the dynamic variable, typically the sequence counter. The old current value is overwritten by the calculated update value. This is step 724. Generally, all the batch commands (after the EXTERNAL 10 AUTHENICATE) are secured. Thus, the successful execution of all the secure commands corresponds to the successful execution of the batch of orders. Another example is when the security level set in parameter P1 of the EXTERNAL AUTHENTICATE command reads "No Secure Messaging Expected", that is, a value of "0" (see section 7.1.2 of GlobalPlatform). ). In this case, only the EXTERNAL AUTHENTICATE command is secure (the following ones are not). The invention therefore allows the replay of the batch of commands only when an unexpected event is performed for this command EXTERNAL AUTHENICATE, limited in fact to the replay of the only protected command, namely the EXTERNAL AUTHENICATE. Following the commitment (commitment) of the new current value of the sequence counter (step 724), the test counter is reset to the default value, "10" in the previous example, in a step 726. Then, in step 722, the slave device 14 sends, to the third device 16 and in response to the last secure command of the batch secure commands, a message including an indication that the execution of all the secure commands of the batch s is successfully completed. This is for example an acknowledgment message in response to this last command of the current batch. As noted above, the last secure command can be identified as such by an indicator, or else derive from the occurrence of the secure command against an expected number of secure commands. The third situation corresponds to a secure command of the batch, whose message authentication code 30 is verified successfully (thus the secure command is integrity and authentic) and which leads to an error or exception of execution of this command. That is, the execution of the command, once decrypted, fails. In other words, this command as defined and encrypted by the master device 12 is erroneous, contaminating the current batch of commands which is therefore also erroneous. This is for example the case when the command indicates a non-existent function on the slave device. Alternatively, it may be a malformed command, with erroneous parameters. In this case, it is not appropriate to make replay of this lot. To avoid these replay, the slave device 14 can force the third device 16 to request again the master device 12, by updating, in non-volatile memory, the current value of the sequence counter with the value of 3027176 22 day currently stored in volatile memory and / or returning an error status that the third party device 16 is able to interpret as the output event of the replay loop. Such a situation can also be detected in step 720, leading to step 724 for the actual update of the sequence counter in nonvolatile memory, then resetting the test counter in step 726 and finally at step 722 where a message is sent to the third party device in response to this command leading to an execution error or exception, the message including an indication of the execution error or exception despite a message authentication code verified successfully. In order to avoid a possible desynchronization of the sequence counter with the test counter (the test counter is reset when the sequence counter in nonvolatile memory is incremented), it is agreed that the step of overwriting the current value in nonvolatile memory and the step of resetting the test counter are performed in an atomic step, i.e. non-divisible, to prevent any malicious person from deflecting the process at this time.
[0030] Other output events leading to the actual commitment of the sequence counter to nonvolatile memory can be envisioned. Another example of an exit event is the case of a MAC code of the EXTERNAL AUTHENTICATE command that is detected as valid while the host cryptogram it contains is detected as erroneous.
[0031] Returning to steps 708 and 710, if the test counter indicates the value "0", i.e. the test counter reaches a threshold value and the maximum number of replay is reached, the device slave 14 calculates the update value of the sequence counter from its current value stored in non-volatile memory; then stores this update value computed in non-volatile memory as the new current value of the counter of 25 sequences (which is thus overwritten). This is step 728. The process then proceeds to step 730 similar to step 726 to reset the test counter; and then retests the test counter value at step 708. This loop ensures the commitment of the new current value of the sequence counter when the maximum number of replay has been reached.
[0032] In order to avoid a possible desynchronization of the sequence counter with the test counter, the step of overwriting the current value in nonvolatile memory and the step of resetting the test counter are performed before step generating the session key from the calculated update value. This provision applies when the attainment of the maximum number of replay is detected on the occasion of a new first command indicating the establishment of a secure channel, for example an INITIALIZE UPDATE command ("yes" to test 708). ). In general, these steps are performed in an atomic step, that is to say not divisible, to prevent any malicious person to deflect the process at this time.
[0033] The loopback on the step 708 makes it possible to process the current batch (all the secure commands of the batch) if this one is already in line with the new current value of counter of sequences. In fact, depending on the level of information that the slave device 14 returns to the third device 16, it is possible for the latter to anticipate the arrival at the limit number of tests, so that obtaining a batch Updated orders can be anticipated. In any case, if the current batch is not yet updated (and is therefore obsolete), it will be updated at the next iteration because the third party device 16 will be informed of the new current counter value of sequences when receiving message 510 (see Figure 5A) in the next step 718.
[0034] Note that in the implementation of Figure 5B, this exchange 510 does not take place. Since the sequence counter is public, a synchronization mechanism can provide the initiative of the third party device or the slave device to communicate to the third party device the current value of the sequence counter. For example, the current value can be automatically returned in response to each first batch command, or solicited by a GET DATA command of the third party device. In the example of FIG. 7, the value of the test counter is compared with the maximum number of possible replay before decrementing (or incrementing) said test counter. One variant may be to reverse the order of these two steps. Figure 8 illustrates, in flowchart form, general steps of an embodiment of the invention at the third device side 16. After initialization, the third device 16 is waiting for receipt of one or more several commands from the master device 12. This is the step 800. Upon receipt, it is determined, in step 802, whether it is a batch (script or batch) of commands pre- generated in predictive mode. If this is not the case, the commands are processed conventionally in step 804, before going back to waiting for a new command (step 800). Otherwise, an index "i" is initialized to 0 in step 806, which index makes it possible to select and process sequentially each of the commands of the received batch. In step 808, the third device 16 sends the command "i" to the slave device 14. If no response is received (test 810), the third device 16 considers that there has occurred an event Unexpected, and proceeds to the replay (arrow 811) of the current batch of commands by returning to step 806. If a response is received, the third device 16 determines, at step 812, whether there has been an occurrence of an unforeseen event, for example because the response indicates that the MAC code of the command is wrong (a transmission error occurred). If this is the case, the third device 16 re-plays (811) the current batch of commands by returning to step 806. If the command has been received correctly by the slave device 14, the third device 16 determines, at the step 814, if the response contains a value of the sequence counter 3027176 24 of the slave device 14. Such information is present in the response to the first INITIALIZE UPDATE command as previously described in connection with FIG. 5. If the value of the counter of sequences of the slave device 14 is indicated in the response, it is compared, in step 816, with a local value stored by the third device 16. If both values are identical, it means that the slave device 14 does not exist. has not updated (in non-volatile memory) its sequence counter since the last iteration, that is to say that the process is in full replay of the same batch of commands. In this case, the command is executed if necessary (step 817) and then the next command of the game is moved by incrementing the index "i" in step 818, which loops back to step 808. If on the other hand the two values are different, it means that the slave device 14 has updated (in non-volatile memory) its sequence counter since the last iteration (either by reaching the maximum number of replay, or because the last batch of commands has been fully processed, or finally because the last batch of orders was intrinsically wrong). In this case, said local value is updated, in step 820, to take the received sequence counter value. Still in step 820, the third device 16 contacts the master device 12 to possibly request a batch of commands updated with the new current value of the sequence counter. Back to test 814, if the received response does not contain a sequence counter value (for example, if it is not the response to the first INITIALIZE UPDATE command in the case of FIG. 5A), the Third-party device 16 determines, in step 821, whether the received response indicates an exit event of the replay loop. In the example of the figure, two tests are proposed. Of course, additional tests to detect other output events can be implemented.
[0035] In step 822, the third party device 16 determines whether the received response indicates an intrinsic control error (the response status takes a predefined code), in which case the local sequence counter value is updated to the step 820, similarly to an update by the slave device 14 (usually in single increment). Indeed, this operation makes it possible to reflect the actual update 724 of the sequence counter operated by the slave device 14. This guarantees a synchronization of the sequence counter between the third device 16 and the slave device 14. Similarly, if the response received indicates that the set of secure commands has been fully processed successfully (test 824 - for example OK in response to the last secure command), the local sequence counter value is also updated to 35 l step 820, similarly to an update by the slave device 14, to reflect the changes in the latter device. Otherwise, no unexpected or exit event occurred, leading to further processing of the other commands via step 818.
[0036] FIG. 9 illustrates, by repeating the diagram of FIG. 5A, exchanges of one embodiment of the invention based on the SCP03 protocol. Steps 5xx remain unchanged from Figure 5A, showing that the present invention is compatible with existing secure channel protocols.
[0037] Note that the explanations below also apply to the predictive mode with the sequencing of Figure 5, or the predictive mode without authentication of Figure 5B. In addition, they apply to other protocols where one or more secure commands are transmitted in a secure channel. In order to synchronize cleanly with the slave device 14, the master device 12 is able to recover the current value of the sequence counter (step 499), from the slave device 14, via the third device 16. For example, this current value can be requested using a GET DATA command (with a flag 9F70), illustrated by the exchanges 900 in the figure. The test counter is decremented (step 714) immediately after receiving the first command indicating the establishment of a secure channel, here the INITIALIZE UPDATE command, as shown by step 902. When this test counter If the maximum number of possible replay is reached, the sequence counter is updated to nonvolatile memory (step 728) and the test counter is reset (step 730). These two steps, corresponding to step 903, are illustrated by the letters "SHIFT" in the figure. Step 904 differs from step 504 in that the update value of the sequence counter is stored in volatile memory (and not in non-volatile memory as in step 504), in order to allow a possible replay. the current batch of orders. The following steps 506-511, 518, 520 are identical to those of FIG. 5A, the slave device 14 then having checked the MAC and the cryptogram contained in the EXTERNAL AUTHENTICATE command, that is to say the very first command. secured by a MAC code. At step 906 completing the processing of the EXTERNAL AUTHENTICATE command, the slave device 14 determines whether an output event of the replay loop has occurred. These events are predefined. In the event of an exit event of the replay loop, the slave device 14 updates the sequence counter in non-volatile memory (step 724), and resets the test counter (step 730) ["MAJ" of the step 906]. An output event of the replay loop is for example a negative check of the host cryptogram of the EXTERNAL AUTHENTICATE command. Optionally (especially if the EXTERNAL AUTHENTICATE command indicates that the following commands are secure), an output event of the replay loop may be the detection of an erroneous MAC of the EXTERNAL AUTHENTICATE command. However, generally, an erroneous MAC (which leads to the closing of the secure channel), and therefore including that of the EXTERNAL AUTHENTICATE command, will be considered as representative of an unexpected event, which allows a replay of the batch of commands. The negative response 522 (NOK) may then comprise (in the optional parameter SW) an error code which is different if it is an output event leading to the update of the current value of the counter. sequences or an unexpected event allowing replay. These error codes are known to the third party device 16. Then each of the subsequent secure commands of the batch of commands is processed (526), processing involving, for the slave device 14 to check the MAC code (528), to decrypt and execute the control (530) and determine if a replay loop output event has occurred, in which case an update of the current value of the sequence counter in nonvolatile memory and a reset of the test counter are performed MAJ "from step 908]. An incorrect MAC code leads to the closing of the communication channel. It is considered an unexpected event allowing replay because this MAC code error can simply result from a transmission error, and not from an error in the batch of commands to be transmitted. An output event of the replay loop is for example an execution error of a secure command having a valid MAC code. In this case, in fact, the secure command is intrinsically erroneous, a replay not making it possible to resolve the source of the error (for example an erroneous or missing parameter in the command). The returned negative response (NOK) may then include (in the optional parameter SW) an error code which is different if it is an output event leading to the update of the current value of the counter of sequences or an unexpected event allowing replay. These error codes are known to the third party device 16.
[0038] Another output event of the replay loop is simply the successful execution of the last secure command of the current batch. Such a "last command" can be directly indicated with the aid of an appropriate flag, or it can be implicit, for example when an initial command indicates the number of future secure commands. Correspondingly, the third device 16 receives the response statuses of the slave device 14, enabling it to determine if an unexpected event or replay loop output event has occurred on the slave device 14. The detection of a output event leads to the update, by the third device 16, of its local counter of sequences ("MAJIoc" in the figure). In particular, thanks to the responses returned by the slave device 14, the third party device 16 detects when it receives a sequence counter value different from the locally stored value (see 912), an error code of the host cryptogram (see 914 ), a message indicating an error in the execution of a valid MAC command (see 916) or a success message for the last batch secure command (see also 916).
[0039] FIG. 9A illustrates the same explanations in the absence of an authentication procedure (FIG. 5B), that is to say when the first command indicating the establishment of a secure channel is itself a secure command. (Figure 1B). Figure 10 illustrates the timing effect of the actual nonvolatile memory update of the sequence counter. The example in the figure is based on a maximum number of replay equals 4, and illustrates the execution of five batches of secure commands. The test counter, initially at 4, is decremented to 3 during the first play test for the first batch of commands, during which a sequence counter update value is stored in volatile memory. This first game (# 1) is a failure (whatever the reason), leading to the replay of the current game. The test counter is then decremented to 2, but this second set (# 2) of the batch is still a failure (the same update value of the sequence counter is stored in volatile memory). The test counter is then decremented to 1, but this third game (# 3) of the batch is still a failure. The test counter is then decremented to 0, but this fourth set (# 4) of the batch is still a failure. When the test counter is detected at 0, the sequence counter is updated to nonvolatile memory, making the current batch of commands obsolete. The third party device 16 obtains a new batch of commands (possibly the same commands, encrypted differently). The test counter is also reset to 4.
[0040] The test counter is then decremented to 3, but the first set (# 5) of the new set is a failure (a new update value of the sequence counter is stored in volatile memory). The test counter is then decremented to 2. The second set (# 6) of the new batch is here a success, leading to update the sequence counter in non-volatile memory. The third party device 16 obtains a third and new batch of commands.
[0041] The test counter is reset to 4. The test counter is then decremented to 3. The first set (# 7) of the new batch is here a success, leading to update the sequence counter in non-volatile memory. . The third party device 16 obtains a fourth and new batch of commands. The test counter is reset to 4.
[0042] The test counter is then decremented to 3, but the first set (# 8) of the new batch is a failure. The test counter is then decremented to 2, but the second set (# 9) of the new batch is a failure. The test counter is then decremented to 1, but the third set (# 10) of the new batch is a failure. The test counter is then decremented to 0, but the fourth and last set (# 11) of the new batch is still a failure.
[0043] Upon detection of the test counter at 0, the sequence counter is updated to nonvolatile memory, rendering the new current batch of commands obsolete. The third party device 16 obtains a new batch of commands (possibly the same commands, encrypted differently). The test counter is reset to 4.
[0044] The process continues in the same way, with the decrementation of the test counter at 3 and with the first set (# 12) of the new batch. The foregoing examples are only embodiments of the invention which is not limited thereto.
[0045] In particular, the above examples show a complete replay of a batch of commands, that is, the first replay command is the first command indicating the establishment of the secure channel, ie INITIALIZE UPDATE in certain modes of SCP02 or SCP03. However, the invention also applies when the first command is a secure command indicating the establishment of a secure channel (see Figure 9A). Thus, alternatively, it may be provided to perform replay from a recovery point provided in the command script, i.e. from a predefined secure command (multiple secure commands forming Restoration points may be provided in the lot). For example, certain secure commands may be indicated by the master device as "restore point" commands, for example every 10 commands. This indication may be provided in the form of a binary flag in the unencrypted header of the commands, so that the third device 16 may be able to interpret it. This indication is treated similarly by the third device 16 and the slave device 14, namely by storing a current context when the command "marked" is executed (the third device receives an acknowledgment). The current context 20 contains in particular the "i" number of the "restore point" command, the session keys, a copy of the last command and the last response (including their MAC codes and one or more CBC counters) in order to allow decryption / encryption of the following commands / responses. Thus, when an unexpected event occurs (power failure, MAC code error), the devices perform a new set of command batch from the last command "restore point" stored in the context saved. It should be noted that if the slave device is not aware of this unexpected event (eg not receiving a command), the next command it receives from the third-party device is the "restore point" command, leading therefore to erroneous verification of the MAC code of this command. The two devices then start a new batch replay from this command "restore point", ensuring effective resynchronization.

权利要求:
Claims (21)
[0001]
REVENDICATIONS1. A method of communication comprising, at a slave device (14), the steps of: receiving (502), from a third party device (16), a command, said first command, indicating the establishment of a channel of secure communication by at least one session key; computing (904) an update value of a dynamic variable from a current value of the dynamic variable stored in nonvolatile memory; generating (506) the session key from the calculated update value; receiving (518, 526) the third party device, at least one command, said second command, secured by a message authentication code; and verifying the message authentication code using the session key before executing said second command; characterized in that it further comprises, at the slave device (14), the steps of: incrementing (902) a test counter upon receipt of the first command indicating establishment of a secure communication channel; and overwriting (724, 728, 903, 906, 908) the current value of the dynamic variable in non-volatile memory with the update value calculated when the test counter reaches a threshold value.
[0002]
The method of claim 1, wherein the step of calculating an update value (904) includes recording the calculated update value in a volatile memory of the slave device.
[0003]
The method according to claim 1 or 2, wherein the current value of the dynamic variable in nonvolatile memory is overwritten (908) in nonvolatile memory with the update value computed when the last secure command of the set of second secure commands includes a validated message authentication code and is executed successfully.
[0004]
The method of claim 3, further comprising the step of: transmitting, to the third party device and in response to said last secure command, a message including an indication that the execution of said second command (s) of the batch is is successfully completed.
[0005]
5. Method according to one of claims 1 to 4, wherein the current value of the dynamic variable in non-volatile memory is overwritten (908) in non-volatile memory with the update value calculated when a second said command whose Message authentication code was successfully verified leading to an error or exception running this second command. 3027176 30
[0006]
The method of claim 5, further comprising the step of: transmitting, to the third-party device and in response to said second command leading to an execution error or exception, a message including an indication of the error or exception execution despite a successfully verified message authentication code. 5
[0007]
7. Method according to one of claims 1 to 6, wherein the test counter is reset (726, 730, 903, 906, 908) to a default value when the current value of the dynamic variable in non-volatile memory is overwritten with the calculated update value.
[0008]
The method of claim 7, wherein the step of overwriting the current non-volatile memory value with the calculated update value (726, 903) and the step of resetting the test counter ( 730, 903) are performed before the step of generating (506) the session key from the calculated update value.
[0009]
The method of claim 7, wherein the step of overwriting the current value in non-volatile memory with the calculated update value (724, 728, 903, 906, 908) and the step of resetting the test counter (726, 730, 903, 906, 908) are performed in one atomic step.
[0010]
10. Method according to one of claims 1 to 6, wherein said first command is a second command secured by a message authentication code. 20
[0011]
11. A method of communication comprising, at a third-party device (16), the steps of: receiving (800), from a master device (12), a batch of commands to be sent to a slave device (14), the batch of commands including a command, called the first command (502), indicating the establishment, with the slave device, of a communication channel 25 secured by at least one session key dependent on a current value of a variable shared dynamic between the master device and the slave device, and at least one command (518, 526), said second command, secured by a message authentication code calculated using the session key; play (808) the batch of commands so as to send, to the slave device, the 30 commands of the batch sequentially, command by command, as long as no error is detected; characterized in that it further comprises, at the third device (16), the following step: replay (811) the batch of commands as long as the third device does not receive, from the slave device (14), a indication of an update of the current value of the dynamic variable by the slave device.
[0012]
The method of claim 11, wherein receiving the update indication of the dynamic variable by the slave device comprises receiving (510, 814) the slave device (12) a current value of the dynamic variable. and comparing (816) the current value received with a local value of the dynamic variable.
[0013]
The method of claim 12, wherein the current value of the dynamic variable is received by the third party device (16) in a response (510) of the slave device (14) to the first command (502).
[0014]
14. The method of claim 11, wherein receiving the indication of an update of the dynamic variable by the slave device comprises receiving (522), the slave device (13), an error message in response to a request. said second command (518) immediately subsequent to the first command (502), the error message indicating an erroneous message authentication code of said second command immediately subsequent to the first command.
[0015]
The method according to one of claims 11 to 14, wherein the indication of an update of the current value includes an indication that the execution of said second command or commands of the batch by the slave device has occurred. successfully completed. 15
[0016]
The method according to one of claims 11 to 15, wherein the indication of an update of the current value comprises an indication that the execution by the slave device (14) of a second command of the batch whose message authentication code has been successfully verified led to an error of this second command.
[0017]
17. The method according to one of claims 1 to 16, wherein the message authentication codes of several second commands are chained.
[0018]
18. Processing device (14) comprising a non-volatile memory storing a current value of a dynamic variable, and a processor configured to: receive, from a third device (16), at least one command, said first command, indicating establishing a secure communication channel with at least one session key; calculate an update value of the dynamic variable from the current value stored in non-volatile memory; generate the session key from the calculated update value; receiving, from the third party device, at least one command, said second command, secured by a message authentication code; and verifying the message authentication code using the session key before executing said second command; characterized in that the processing device further comprises a test counter, and the processor is further configured to: increment the test counter upon receipt of the first command indicating the establishment of a secure communication channel ; and overwriting the current value of the dynamic variable in non-volatile memory with the calculated update value when the test counter reaches a threshold value.
[0019]
19. Processing device (16) comprising a processor configured to: receive, from a master device (12), a batch of commands to be sent to a slave device (14), the batch of commands including a command, said first command, indicating the establishment, with the slave device, of a secure communication channel by at least one session key dependent on a current value of a dynamic variable shared between the master device and the slave device, and at least one command, said second command, secured by a message authentication code calculated using the session key; play the batch of commands so as to send, to the slave device, said commands of the batch sequentially, command by command, as long as no error is detected; characterized in that the process is further configured to: replay the batch of commands as long as the processing device does not receive, from the slave device, an indication of an update of the current value of the dynamic variable by the device slave. 15
[0020]
A system (10) comprising a slave device (14) according to claim 18, a third-party device (16) according to claim 19, and a master device (12) configured to generate and send the batch of commands to the third-party device (16). ).
[0021]
21. Computer program product comprising instructions adapted to the implementation of each of the steps of the method according to any one of claims 1 to 17, when said program is run on a computer.

类似技术:

---

公开号 | 公开日 | 专利标题

---

EP3010175B1|2019-04-10|Replay of a batch of secure commands in a secure channel

---

EP1427231B1|2011-08-31|Method of establishing and managing a confidence model between a SIM-card and a mobile terminal

---

EP3152860B1|2021-05-05|Method for the authentication of a first electronic entity by a second electronic entity, and electronic entity implementing such a method

---

EP3732818B1|2021-09-29|Method and system for cryptographic activation of a plurality of equipement items

---

EP2741466B1|2018-02-14|Method and system for managing a built-in secured element eSE

---

EP3238200A1|2017-11-01|Secure electronic entity, electronic apparatus and method for verifying the integrity of data stored in such a secure electronic entity

---

EP3185468B1|2019-09-25|Data-transmission method, data-receiving method, corresponding devices and programs

---

CN109474420A|2019-03-15|A kind of private key backup method and relevant device

---

FR3046000A1|2017-06-23|METHOD FOR RECEIVING DATA WITHIN AN ELECTRONIC ENTITY AND ELECTRONIC ENTITY THEREFOR

---

EP2859497B1|2020-07-29|Method for backing-up data outside of a secure microcircuit

---

EP3238474B1|2019-03-13|Method for securing contactless transactions

---

EP3014849B1|2018-08-01|Method for changing an authentication key

---

FR3092954A1|2020-08-21|Network key recovery, network key sending, network key recovery management, terminal, mediation server and access point implementing them

---

EP3327607A1|2018-05-30|Data verification method

---

FR3112643A1|2022-01-21|Apparatus, method and program for secure communication between white boxes

---

EP3743871A1|2020-12-02|Secure system for transactions between terminals

---

FR3037167A1|2016-12-09|METHOD FOR PROVIDING A INSTALLATION SCRIPT TO A SECURE MODULE, SECURE MODULE AND PROVISIONING SERVER

---

WO2016034812A1|2016-03-10|Securing of encryption keys for transactions on a device lacking a secure module

---

WO2017060624A1|2017-04-13|Means for managing access to data

---

EP1321005A1|2003-06-25|Method for implanting data on an identifier

---

EP3140951A1|2017-03-15|Electronic entity and method for generating a session key

---

FR3028697A1|2016-05-20|IMPROVING THE AUTHENTIC INTEGRITY OF DATA USING THE LATEST BLOCK ENCRYPTING THESE DATA IN CBC MODE

---

WO2011098702A1|2011-08-18|Single-use password authentication

同族专利:

---

公开号 | 公开日

---

ES2737703T3|2020-01-15|

---

EP3010175A1|2016-04-20|

---

KR20160043520A|2016-04-21|

---

US20160105411A1|2016-04-14|

---

FR3027176B1|2016-12-09|

---

EP3010175B1|2019-04-10|

---

US9787663B2|2017-10-10|

---

KR101838191B1|2018-03-14|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

US20040148502A1|2001-02-22|2004-07-29|Michael Gollner|Method and system for the distributed creation of a program for a programmable portable data carrier|

---

US20120159502A1|2010-12-16|2012-06-21|International Business Machines Corporation|Variable increment real-time status counters|

---

US20090215490A1|2008-02-27|2009-08-27|Mediatek Inc.|Methods for handling proactive commands for one or more subscriber identity cards and systems utilizing the same|

---

USH2270H1|2009-07-09|2012-06-05|Actividentity, Inc.|Open protocol for authentication and key establishment with privacy|

---

EP2452297A4|2009-07-10|2014-05-28|Certicom Corp|System and method for managing electronic assets|

---

FR2980607B1|2011-09-27|2014-04-25|Proton World Int Nv|KEY DERIVATION METHOD IN AN INTEGRATED CIRCUIT|

---

US9317467B2|2012-09-27|2016-04-19|Hewlett Packard Enterprise Development Lp|Session key associated with communication path|DE102015012941B3|2015-10-07|2017-04-06|Giesecke & Devrient Gmbh|A method for loading a profile using a loading package|

---

US20180018221A1|2016-07-15|2018-01-18|Advanced Micro Devices, Inc.|Ddr memory error recovery|

---

US10394674B2|2016-08-24|2019-08-27|Apple Inc.|Local recovery of electronic subscriber identity moduleinstallation flow|

---

US10341304B1|2017-01-04|2019-07-02|Snap Inc.|Device independent encrypted content access system|

---

US10585726B2|2017-05-16|2020-03-10|Electronics And Telecommunications Research Institute|Parameter-sharing apparatus and method|

---

DE102017212994B3|2017-05-31|2018-11-29|Apple Inc.|INSTALLATION AND TESTING OF AN ELECTRONIC PARTICIPANT IDENTITY MODULE |

---

CN108768621B|2018-03-27|2021-03-26|王晓华|Password acquisition method, verification method, related device, equipment and system|

---

CN108712246B|2018-03-27|2021-08-10|王晓华|Intelligent household equipment and system and visitor password acquisition method|

---

DE102018009835A1|2018-12-14|2020-06-18|Giesecke+Devrient Mobile Security Gmbh|Incremental firmware update|

法律状态:
2015-09-28| PLFP| Fee payment|Year of fee payment: 2 |

---

2016-04-15| PLSC| Search report ready|Effective date: 20160415 |

---

2016-09-21| PLFP| Fee payment|Year of fee payment: 3 |

---

2017-09-21| PLFP| Fee payment|Year of fee payment: 4 |

---

2018-09-19| PLFP| Fee payment|Year of fee payment: 5 |

---

2019-09-19| PLFP| Fee payment|Year of fee payment: 6 |

---

2020-09-17| PLFP| Fee payment|Year of fee payment: 7 |

---

2020-11-27| CA| Change of address|Effective date: 20201019 |

---

2020-11-27| CD| Change of name or company name|Owner name: IDEMIA FRANCE, FR Effective date: 20201019 |

优先权:

---

申请号 | 申请日 | 专利标题

---

FR1459800A|FR3027176B1|2014-10-13|2014-10-13|REJECTING A BATCH OF SECURE COMMANDS IN A SECURE CHANNEL|FR1459800A| FR3027176B1|2014-10-13|2014-10-13|REJECTING A BATCH OF SECURE COMMANDS IN A SECURE CHANNEL|

---

US14/879,449| US9787663B2|2014-10-13|2015-10-09|Replaying a batch of secure commands in a secure channel|

---

ES15189420T| ES2737703T3|2014-10-13|2015-10-12|Reinjection of a batch of secure commands on a secure channel|

---

EP15189420.1A| EP3010175B1|2014-10-13|2015-10-12|Replay of a batch of secure commands in a secure channel|

---

KR1020150143126A| KR101838191B1|2014-10-13|2015-10-13|Replaying a batch of secure commands in a secure channel|